1. Technical Field
The present invention relates to packet-data communications and, more particularly, to improving the performance, reliability, and security of packet-data communications, including voice communications.
2. Description of Related Art
a. Generally
More people than ever are using mobile stations, such as cell phones and personal digital assistants (PDAs), to connect to wireless wide area networks (WWANs), which are also referred to as cellular wireless communication systems, cellular wireless networks, and by other names. WWANs typically provide both voice and packet-data communication using a wireless communication format such as Code Division Multiple Access (CDMA), or another format.
In addition to WWANs, wireless local area networks (WLANs) are becoming increasingly popular. Typical WLANs cover an area that is geographically smaller than that covered by typical WWANs, and often provide a signal in that area that is superior to that provided by the WWAN. For example, a WLAN may cover a residence, a building, or a proximally-located group of buildings, perhaps on a corporate or academic campus.
WLANs typically provide a wireless coverage area and access to a packet-data network via one or more “access points.” That packet-data network could operate according to the Internet Protocol (IP), and devices communicating over that network may each have an address known as an IP address. A common use of a WLAN is packet-data communication by a laptop computer, or perhaps by another device such as a digital video recorder. A commonly-used set of protocols for wireless communication between and among these access points and devices are those specified by the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards.
b. VoIP and Multi-Mode Devices
Recently, the telecommunications industry has witnessed widespread growth in the area of voice-over-IP (VoIP) technology; that growth, combined with the ever-increasing prevalence of mobile stations engaging in packet-data communication generally, has caused the industry to begin to introduce mobile stations (“multi-mode devices”) that are equipped to engage in both (i) voice and packet communications via WWANs (using, e.g., CDMA) and (ii) packet-data communications (including VoIP communications) via WLANs (using, e.g., 802.11).
In one arrangement, for instance, a cellular wireless carrier may operate a gateway that provides connectivity between a packet-switched network and the wireless carrier's transport and signaling networks. The carrier may then distribute to its subscribers multi-mode devices, which may be capable of communicating in a WWAN mode with one or more types of WWANs and capable of communicating in a WLAN mode with one or more types of WLANs.
When a multi-mode device is within the coverage area of the carrier's WWAN infrastructure, the device may operate conventionally as a standard cellular telephone, with signaling passing through the carrier's signaling network and bearer data passing through the carrier's transport network. When the multi-mode device moves into the coverage area of a WLAN access point, on the other hand, the device may engage in IP-based signaling and IP-based bearer communication with the carrier's gateway, which may then interface the signaling and bearer communications with the carrier's signaling and transport networks.
c. Private Network Addressing
With respect to assigning IP addresses to devices communicating with each other over a typical WLAN, this is often done using what are known as private IP addresses. A private IP address is one that is routable over the network on which it is used, but not routable beyond that network. In fact, a device on one private network may have the exact same private IP address as another device on another private network. This illustrates why those private IP addresses are not routable in a global sense, or even beyond their own private networks. Relevant aspects of private network addressing are discussed in Rekhter et al., “Address Allocation for Private Internets,” RFC 1918 (February 1996), which is incorporated herein by reference.
d. Network Address Translation
One method that has been developed to enable privately-addressed devices residing on private networks to communicate with devices on other networks is known as “network address translation (NAT). Relevant aspects of NAT are described in Srisuresh & Holdrege, “IP Network Address Translator (NAT) Terminology and Considerations,” RFC 2663 (August 1999) and Srisuresh & Egevang, “Traditional IP Network Address Translator (Traditional NAT),” RFC 3022 (January 2001), which are incorporated herein by reference.
Typically, NAT involves a device (a “NAT device”) that resides between the private network and another network, and that has a network address on both networks. As an example, the other network could be a public IP network such as the Internet. Note that NAT can also be performed between two private networks, or between two public networks. Returning to the example of one private network and one public network, when the NAT device receives an IP packet from a device on the private network that is addressed to a device on the public network, the NAT device changes the source IP address of the packet from the device's private address on the private network to the NAT device's public address on the public network.
However, since multiple privately-addressed devices may communicate over the public network via the NAT device, the NAT device must also keep track of which device sent the packet. One way the NAT device may do so is by selecting a transport-protocol port number for each device. As examples, the transport protocol could be the well-known User Datagram Protocol (UDP) or Transport Control Protocol (TCP). Thus, in addition to modifying the packet's source IP address, the NAT device may also modify a transport-protocol source port number for the packet, to identify the device on the private network.
When the NAT device receives an inbound packet, that inbound packet will typically have the NAT device's public address as the destination IP address and the port number previously chosen by the NAT device as the destination port number. The NAT device will thus be able to determine to which privately-addressed device to transmit the packet. The NAT device will then modify the inbound packet by changing the destination IP address from the NAT device's public IP address to the privately-addressed device's private IP address. The NAT device will typically also modify the inbound packet's destination port number to be equal to whatever source port number was originally used by the privately-addressed device. Note that a NAT device may have other ways of keeping track of privately-addressed devices.
e. Security Considerations and Protocols
Another important consideration in today's electronic-communication environment is the security of particular communications. Security measures commonly involve implementing authentication and encryption with respect to data transmissions. One well-known method of providing data-transmission security is known as the IP Security protocol suite, or IPSec. Relevant aspects of IPSec are discussed in Kent & Atkinson, “Security Architecture for the Internet Protocol,” RFC 2401 (November 1998), which is incorporated herein by reference.
One well-known method of providing data encryption is known as the IP Encapsulating Security Payload, and is often abbreviated “ESP.” Relevant aspects of ESP are described in Kent & Atkinson, “IP Encapsulating Security Payload (ESP),” RFC 2406 (November 1998), which is incorporated herein by reference. A methodology often employed in establishing and maintaining secure relationships between devices is known as the Internet Key Exchange (IKE), relevant aspects of which are described in Harkins & Carrel, “The Internet Key Exchange (IKE),” RFC 2409 (November 1998), which is incorporated herein by reference.
One term that is commonly used to describe a secure relationship between data-communication devices is a virtual private network (VPN) or VPN tunnel. Once a VPN tunnel is established between two or more communication devices, perhaps using the above-referenced security protocols, and/or perhaps other security and communication protocols, the devices can securely exchange packet data “inside” the VPN tunnel. Typically, this data would be encrypted using an encryption algorithm known to the devices connected via the VPN tunnel. The encrypted data would then be encapsulated with headers comprising IP addresses routable over the network or networks linking the devices. The data could then be decrypted on the receiving end according to the agreed-upon parameters of the VPN tunnel.
f. Security Implementations and Network Address Translation
Certain compatibility issues have arisen when attempts have been made to implement VPN tunnels (using, for example, IPSec) in contexts involving one or more NAT devices. One basic reason for the arising of these issues is that the VPN-tunnel implementations consider the modifications to the addresses and perhaps port numbers made by the one or more NAT devices to be an intolerable alteration to the packet data. These issues, as well as approaches to dealing with them, are discussed in Aboba & Dixon, “IPsec-Network Address Translation (NAT) Compatibility Requirements,” RFC 3715 (March 2004), Kivinen et al., “Negotiation of NAT-Traversal in the IKE,” RFC 3947 (January 2005), and Huttunen et al., “UDP Encapsulation of IPsec ESP Packets,” RFC 3948 (January 2005), which are incorporated herein by reference.
g. Mobile IP
Many communication devices in today's environment implement a mobility protocol known as the Mobile Internet Protocol (Mobile IP), relevant aspects of which are discussed in Perkins, “IP Mobility Support for IPv4,” RFC 3344 (August 2002), which is incorporated herein by reference. In Mobile IP, devices (known as “mobile nodes”) are able to maintain a static or at least semi-permanent IP address even when changing their point of attachment to the Internet. This IP address is known with respect to the mobile node as a home address.
To maintain the ability to engage in IP communication even when changing its point of attachment to the Internet, a mobile node registers with a device known as a home agent, which resides on a network known with respect to the mobile node as a “home network.” As a result of this registration, the home agent stores an association between the mobile node's home address and a “care-of address” for the mobile node. Packets addressed to the mobile node's home address are intercepted by the home agent on the home network and tunneled by the home agent to the mobile node's registered care-of address.
This care-of address could be a “co-located care-of address” or a “foreign-agent care-of address.” If the care-of address is a co-located care-of address, that address would typically be an address of the mobile node on the network to which the mobile node is currently attached. If the care-of address is a foreign-agent care-of address, that address would typically be an IP address of a separate device on the network to which the mobile node is currently attached. That device and network would be known to the mobile node as a foreign agent and a foreign network, respectively. The foreign agent would receive packets tunneled from the home agent, and forward those packets to the mobile node. The foreign agent could also tunnel outgoing packets from the mobile node to the home agent.
h. Mobile IP and Network Address Translation
One or more NAT devices could be present between a mobile node and its home agent, which creates a number of compatibility issues. Some of these issues, as well as an approach to handling them, are discussed in Levkowetz & Vaarala, “Mobile IP Traversal of Network Address Translation (NAT) Devices,” RFC 3519 (April 2003), which is incorporated herein by reference. The basic problem has been routing of packets to the correct mobile node, when those packets pass through a NAT device. The basic solution described in RFC 3519 involves use of a particular UDP port that the NAT device can use to map to the correct mobile node.
i. Conclusion
In the context of a service provider providing packet-data service to customers, certain additional considerations arise as well. For example, service providers can typically obtain only a limited number of public IP addresses from the various Internet registries such as Internic. As such, it is important to a typical service provider to use those addresses as efficiently as possible.
Also, for security reasons, service providers typically prefer that certain of their network entities not be directly accessible via a public Internet address. Rather, the service providers prefer to “hide” these entities behind publicly-addressed devices such as gateways. Some examples of network entities about which a typical service provider may have such a preference are Session Initiation Protocol (SIP) servers, Real-time Transport Protocol (RTP) servers, and Wireless Application Protocol (WAP) gateways.
A third consideration is that, especially in the context of packet-data-communication applications such as VoIP, performance is greatly enhanced by keeping the percentage of each packet that is made up of user data (rather than meta-data such as headers) as high as possible.
In summary, none of the current proposals for handling the various intersections of the various technologies mentioned above (Mobile IP, NAT, security/privacy tools, etc.) adequately achieve Mobile-IP registration and Mobile-IP VoIP communication in a secure, private manner, in a way that reliably traverses NAT, conserves a service provider's publicly-routable address space, guards as many service-provider network entities as possible from having to be publicly accessible via the Internet, and maximizes the percentage of user data per packet.